The present invention relates generally to data processing systems. More particularly, it relates to systems to produce a plurality of different output files for programs.
The development of programming for data processing systems has traditionally been a time consuming task. Object oriented programming (OOP) has emerged as a promising new technology which will allow more efficient development reuse and customization of new software programming. Object oriented programming shifts the emphasis of software development away from function decomposition and towards the recognition of units of software called "objects" which both encapsulate data and function. As a result, programs become easier to maintain and enhance.
Yet despite its promise, object oriented technology has not penetrated major commercial software products to date. This is due in part because of the obstacles which the developer must confront when utilizing object oriented programming. A first obstacle that developers must confront is the choice of which object oriented programming language to use. The early expressions of object oriented programming concept focused on the creation of tool kits and languages, each of which are designed to exploit some particular aspect of OOP. So called, pure object oriented languages such as SmallTalk use a run time environment which will operate smoothly and consistently so long as the developer works within the supplied environment. However, when interacting with foreign environments, the objects must be reduced to data structures which do not retain the advantages which objects offer with regard to encapsulation and code use. Hybrid languages, such as C++ require less run time support, but can result in tight bindings between the programs which provide the objects and the clients which use them. Tight binding implies that the client programs must be recompiled whenever simple changes are made to the library. The second obstacle is the disparity in concept among the plurality of different object oriented languages; tool kits embrace different incompatible models of what objects are and how they work. The software developed using any particular language or tool kit is limited in scope. A program implemented in one language can rarely be used in another.
The System Object Module "SOM" is a new object oriented technology for building packaging and manipulating object oriented programs designed to unite various object oriented approaches. In SOM, the interfaces of the classes of Objects, together with the names of the method they support, the return types, the parameter types and so forth, are specified in a standard language called. the Interface Definition Language (IDL). The actual implementation of the object class can be performed in whatever programming language the developer prefers. The preferred programming language need not necessarily be an object oriented programming language, but might be a procedural language such as C. Thus, the advantages of object oriented programming can be extended to programmers non object oriented programming languages. SOM is described in greater detail in the OS/2 2.0 SOM Guide and Reference a publication of the IBM Corporation, which is hereby incorporated by reference.
The SOM compiler translates the IDL interface specification into a variety of different output forms. The interface definition can be translated into a programming language binding file an implementation template file, a documentation file, a description that can drive a class browser or a printed interface specification. The structure of the SOM compiler is divided into an IDL parser which understands the interface definition in IDL and translates in an abstract syntax graph an intermediate language. It also includes an emitter which translates intermediate language to the desired output form. A plurality of different output forms are supported by having interchangeable emitters, however, to date each emitter must be programmed by hand, which is a laborious and time consuming effort.
One of tile problems occurs in SOM when a developer wishes to add new methods or change existing ones or change the interface to an already existing class. The SOM compiler can not simply generate a new implementation file for the existing implementation code would be lost. Instead, the compiler must somehow merge the existing implementation file with the newly generated one while preserving programmer added code and the order of functions within the implementation files.
This invention teaches technique for automatically merging two compiler generated files.
It is therefore an object of the invention to merge two compiled files generated for substantially identical purposes.
It is another object of the invention to preserve the order in which modules occur in the two files.
It is another object of the invention to preserve programmer added code in the merged file.